odd spacing

Is the plan for the store to implement MVCC based on index or the version of the key? If so, would a range request be able to filter on a maximum index? I didn't know whether the underlying store would include MVCC, or whether that would be the level above the store (imposed as the last key segment by the etcd simple api).

Range query is done atomically. The underlay store is MVCC, so it is low cost.

So then adding an optional int64 max_index to this struct would not break the underlying model and also allow you to do range queries where you get the latest resource up to index X?

The use case I'm asking about is being able to do consistent paged range queries,

1. get initial range min_key=start limit=100 max_index=0,
2. read index from initial range Y and max key Z
3. get next range min_key=Z max_index=Y limit=100
4. repeat

@smarterclayton
Let us be more clear here.

foo = bar  [index 1]
foo = bar00 [index 2]
range query all -> foo = bar00; range query (all, max_index=1) -> nothing
foo1 = bar  [index 3]
range query all -> foo = bar00; foo1 = bar 1; range query (all, max_index=2) -> foo = bar

Is this what you want?

We are not going to keep all versions in the key value space.

Instead, You can get the old versions only by scanning the history.
You can range scan the history via watch.

@smarterclayton All the old versions of keys can be retrieved from the history store, which is sorted by logic time order.

On Apr 14, 2015, at 12:03 PM, Xiang Li notifications@github.com wrote:

In Documentation/rfc/v3api.md:

• // the cluster id to check with
• // if the cluster id is not matched, an error is returned.
• optional uint64 cluster_id = 1;
  +}

+message ResponseHeader {

• // an error type message?
• optional string error = 1;
• optional uint64 cluster_id = 2;
• optional uint64 member_id = 3;
• // index of the store when the requested was processed.
• optional int64 index = 4;
• optional uint64 raft_term = 5;
  +}

+message RangeRequest {
@smarterclayton

The current API does not directly support consistent range over multiple requests. You can build your own via range + history.

Do you have a real use case? What are you trying to solve?

For Kubernetes, there are advantages to being able to do ranged snapshot queries to process data in chunks (instead of loading 100k keys in memory at once, make 100 1K range requests). We can do that via buckets in the keyspace, but the larger appeal of range was the consistent chunk aspect.

That being said, it does not break our use cases if that's not available. I believe in order to emulate that we would need delete tombstones in the key space and would have to track the highest modified index in the scan. Do you anticipate/expect there to be delete tombstones in the keyspace?

—
Reply to this email directly or view it on GitHub.

Do you anticipate/expect there to be delete tombstones in the keyspace?

The tombstones is in the event history. Do a range query with max_index. Fill in the gaps via another range query over the history from the max_index to now.

Does that make sense to you?

We can do the consistent query too. But it would make the API a little bit complicated. For each range query, we will return you a range ID and a timeout. Within the timeout, you can get consistent snapshot.

On Apr 14, 2015, at 12:21 PM, Xiang Li notifications@github.com wrote:

In Documentation/rfc/v3api.md:

• // the cluster id to check with
• // if the cluster id is not matched, an error is returned.
• optional uint64 cluster_id = 1;
  +}

+message ResponseHeader {

• // an error type message?
• optional string error = 1;
• optional uint64 cluster_id = 2;
• optional uint64 member_id = 3;
• // index of the store when the requested was processed.
• optional int64 index = 4;
• optional uint64 raft_term = 5;
  +}

+message RangeRequest {
Do you anticipate/expect there to be delete tombstones in the keyspace?

The tombstones is in the event history. Do a range query with max_index. Fill in the gaps via another range query over the history from the max_index to now.

Does that make sense to you

Yes, I think so.
We can do the consistent query too. But it would make the API a little bit complicated. For each range query, we will return you a range ID and a timeout. Within the timeout, you can get consistent snapshot.

I don't want to overcomplicate the store or API, certainly. I think consistent paged range queries are valuable on their own to a wide range of users, as long as it does not break the core consistency guarantees of the store. But I may also be bringing my own assumptions to the discussion. If easy to emulate above, or can lead to complex problems on failover, it doesn't need to be in the API.
—
Reply to this email directly or view it on GitHub.

@smarterclayton Sure. We will keep that in mind. We will have another iteration on the API soon.

Split into a .proto file for further comment (and ultimately copy!)

Should this be separate or be part of the generic Tnx?

i wil explore more. i am not a big fan of this api either.

hmm... after think this for a while, i think we should still let the lease know about tnx (a key space operation) instead of letting the key operation knowing about the lease.

Unused?

Is this part of RequestUnion?